my comments re the implementation: scala/scala3#7468

1. The proposal needs to be somewhat self contained. Make sure to fill out all the template.
2. Please discuss pros/cons to https://contributors.scala-lang.org/t/pre-sip-sharp-string-interpolation/5836/50

@bishabosha I think this concern is made obsolete by implicit conversions being removed.

I think this concern is made obsolete by implicit conversions being removed

Well they aren't removed yet 😅

I meant going to be removed.

@soronpo I think the tension is around the concept of target typing (not unrelated to the discussion on relative scoping for hierarchical ADT arguments BTW). The current generic number literals proposal relies heavily on it. In consequence, it has limited power, as outlined for instance by @sjrd in the generic number literals pull request. Besides, it could be covered by existing string interpolation:

bi"10_000_000_000"

, for which your proposal is just an improvement:

big#345463489989893859438943643

. But the current proposal would allow a constructor based, quote less syntax that suits my own use case (computer algebra) quite well:

BigInteger(345463489989893859438943643)

, as long as I can define said constructor as follows:

object BigInteger:
  def apply(x: BigInteger) = x

. Here we have an expected type BigInteger so it will always work, and the syntax is not that bad (and better, IMHO, than any form of string interpolation).

Here we have an expected type so it will always work

Not always. Only when there is an explicit destination type. Implicit conversions or type-classes are not applicable. Huge blocker IMHO.

My destination type is BigInteger. (I assumed there is a FromDigits[BigInteger].)

My destination type is BigInteger. (I assumed there is a FromDigits[BigInteger].)

I understand your use case. The motivation for the feature is lacking since it does not cover the situations where the destination type is not BigInteger, but something that can be a typeclass of BigInt or converted to it. Without handling such a case, I don't think this feature is good enough.

And if truly the only relevant use-case is big literals, I would opt for a Big Literal SIP instead of the generic numeric literals that are not really generic enough.

Right, regarding BigInt, we need to see if such a constructor is useable, knowing that overloads have a tendency to perturb target typing. Also agreed there are not many use cases past BigInt/BigDecimal.

That said, as explained elsewhere, in the context of my project, my strategy is to do without BigInt and rely on type classes / extension methods to enrich BigInteger. So a numeric literal mechanism generic enough to cover it is still needed.

To summarize, to be able to move forward with this proposal please:

1. Make the proposal self contained. Motivation, specification and the rest need to be part of the proposal and not links.
2. Motivation and use-cases are important if we're to assess if this proposal addresses them and if not, why they are not crucial/common enough.

Regarding the BigInt use case, one can always define a MyBigInt constructor as so:

object MyBigInt:
  def apply(x: BigInt) = x

But again, adding a constructor is just to address the shortcomings of target typing, and the main use case of writing big numbers as, like, numbers, is still relevant and well worth de-experimental-ifying the feature (as-is). WDYT?

val x: BigInt = 111111100000022222222222